El seguimiento del proyecto se ha apoyado en tres herramientas que operan de forma complementaria: Git como sistema de control de versiones y fuente de verdad de la actividad técnica, Obsidian como sistema de documentación y gestión del conocimiento, y Claude Code como asistente de desarrollo con el que se ha automatizado la generación del registro semanal de commits. A continuación se describe cada una de ellas, su fundamento conceptual y el uso concreto que se les ha dado en este proyecto.

Control de versiones con Git

Como cualquier informático sabe, Git es un sistema de control de versiones distribuido que registra los cambios en el código fuente a través de commits: instantáneas atómicas del estado del repositorio en un momento dado. Cada commit lleva asociado un mensaje descriptivo, un autor, una marca temporal y un hash que lo identifica de forma única. Esta estructura convierte el historial de commits en una bitácora precisa de la actividad de desarrollo, con trazabilidad completa de qué se cambió, cuándo y por qué.

En este proyecto, el código reside en el repositorio xabet-digitalwall, sobre la rama tfg/martin, aislada de la rama principal develop de la empresa para evitar interferencias con el trabajo del equipo. Los commits de esta rama, filtrados por autor, constituyen la fuente primaria de evidencia del trabajo técnico realizado en cada semana. Adicionalmente, la propia documentación del TFG está versionada en un repositorio Git separado, el vault de Obsidian, cuya rama main recoge los commits de planificación, notas de decisión y resúmenes de seguimiento. Ambos repositorios se consultan de forma conjunta en el proceso de generación del registro semanal.

Obsidian como sistema de documentación

Obsidian es una aplicación de gestión del conocimiento basada en archivos Markdown locales enlazados mediante sintaxis wiki-link (nota). A diferencia de herramientas de documentación en la nube, Obsidian opera sobre el sistema de archivos local, lo que permite versionar el vault completo en Git y mantener control total sobre los datos. Su modelo de notas interconectadas favorece la creación de una red de conocimiento donde cada decisión técnica, diagrama o resumen puede enlazarse con las notas relacionadas.

En este proyecto, el vault actúa como el repositorio central de documentación del TFG. Dentro de University/TFG/, cada objetivo EDT tiene su propia carpeta, y cada una de ellas cumple una doble función: por un lado, contiene los borradores y notas que alimentan directamente la memoria del proyecto; por otro, recoge apuntes de trabajo más informales —ideas espontáneas, tareas pendientes, razonamientos en curso— que capturan el proceso de pensamiento en el momento en que ocurre. Las notas de decisión arquitectónica, almacenadas en 5_BDV/notes/ y carpetas equivalentes de otros objetivos, son el ejemplo más claro de esto: documentan el razonamiento detrás de cada elección de diseño con el contexto que el historial de commits por sí solo no puede capturar. Fuera de la carpeta TFG, el mismo vault recoge los apuntes de los cursos que el alumno ha cursado para formarse en las tecnologías del proyecto, centralizando así tanto el trabajo como el aprendizaje en un único entorno versionado.

Esta estructura de documentación, combinada con el uso de Claude Code como asistente de desarrollo con acceso al sistema de archivos, permite reunir y mantener actualizada una cantidad de información que sería inviable gestionar de forma manual.

A posteriori, claro está, la formalización del documento se ha llevado a cabo en Overleaf, un editor de LaTeX colaborativo en la nube que permite redactar documentos con tipografía profesional sin necesidad de instalar una cadena de compilación local.

De esta forma, la memoria formal del TFG se redacta íntegramente en Overleaf, mientras que el vault de Obsidian actúa como un entorno de trabajo previo, donde se elaboran los borradores, se toman notas, se estructura el contenido y se apuntan las tareas del proyecto. El flujo habitual consiste en redactar y madurar una sección en Obsidian, y trasladarla a Overleaf una vez consolidada, adaptando el contenido a la sintaxis LaTeX y ajustando la presentación visual del documento final.

Claude Code y el paradigma de skills

Claude Code es una interfaz de línea de comandos para el modelo Claude de Anthropic que permite interactuar con el asistente directamente desde el terminal, con acceso a las herramientas del sistema: lectura y escritura de ficheros, ejecución de comandos shell, búsquedas en el repositorio. Esto lo convierte en un asistente de desarrollo que puede actuar sobre el código y la documentación del proyecto, no solo generar texto.

Una de sus capacidades más relevantes para este TFG es el sistema de skills (también llamados slash commands o custom commands): archivos Markdown almacenados en ~/.claude/commands/ que actúan como prompts de sistema especializados. Cuando el usuario invoca /nombre-del-skill <argumentos>, Claude Code lee ese archivo como instrucción y lo ejecuta combinando razonamiento en lenguaje natural con llamadas a herramientas del sistema. El skill no es código ejecutable en el sentido tradicional: es una especificación en lenguaje natural que el modelo interpreta y traduce en una secuencia de acciones concretas.

Usuario: /obsidian log-commits --n 5
         ↓
Claude Code lee ~/.claude/commands/obsidian.md
         ↓
Interpreta la operación "log-commits"
         ↓
Ejecuta git log + git show → analiza → escribe en el vault

Una de las skills desarrolladas específicamente para este proyecto es /obsidian, cuya función es la asistencia en la gestión documental del vault y, en particular, la generación de los análisis semanales de la actividad de commits. Su operación de registro consulta simultáneamente los dos repositorios del proyecto —xabet-digitalwall en la rama tfg/martin y el vault de Obsidian en main— recupera los commits del período indicado y genera automáticamente una entrada en 3_SyC/commits_summary/ con el análisis de la actividad de esa semana.

El flujo completo de la operación es el siguiente: para cada commit recuperado, se obtiene el detalle de los ficheros modificados mediante git show --stat; a partir de los paths de esos ficheros se infiere el objetivo EDT al que pertenece el trabajo (por ejemplo, commits en paths embeddings-* se mapean a BDV, ficheros .vue a IUX, cambios en University/TFG/3_SyC/ a SYC); los commits funcionalmente relacionados se agrupan para analizarlos como una unidad de trabajo coherente; y finalmente se redacta en español un análisis de qué se hizo y qué relevancia tiene para el TFG. El resultado se añade al archivo de la semana correspondiente, creándolo si no existe, y omitiendo los hashes que ya hubieran sido registrados en ejecuciones anteriores.

Incluir el vault de Obsidian en el análisis es una decisión deliberada: escribir notas de decisión arquitectónica, refinar la planificación o mejorar el propio skill son en sí mismos trabajo del TFG encuadrado en el objetivo SYC. Capturar esos commits cierra el bucle de documentación y garantiza que el registro semanal refleja la actividad real del proyecto en su totalidad, no solo la parte de código.

El skill completo, incluyendo todas sus operaciones y las reglas de inferencia EDT, se mantiene sincronizado en 3_SyC/skills/obsidian_skill_definition.md como documentación viva de la herramienta.